PDP-1 COMPUTER 
ELECTRICAL ENGINEERING DEPARTMENT 
M«I»T» 
CAMBRIDGE, jymSSACHU3ETTS 02139 



PDP-39 

DRUM SCHEDULING TECHNIQUES 
In the PDP-i-X 



June 8, 1966 



-1- 

DRUM SCKEDQUNG TECHNIQUES in the PDP-l-X 
In the following we assume that the Job mix for the 
drum consists of 400o-word transfers intended to move blocks 
of a file, and iGGGOg-word transfers called for by the 
computation scheduling algorithm as it moves program image 
sections in and out of core. We assume that the drum has 
a "swap" instruction, which pauses the entire contents of 
a specified field on the drum to be written from, or read 
into, a specified field of core. This transfer starts as 
soon as possible after the instruction is given, independent 
of the current drum address, and occupies one drum revolution. 

The drum mover maintains a drum job queue of 400g-word 
jobs and the scheduling algorithm maintains the queue of 
lOOOOo-word jobs. The drum mover process, on being restarted 
when the drum completes a transfer, first checks the scheduling 
algorithm^ queue, and performs a iOQOOg-word job if one 
is there. If not, it performs the first job in its queue. 

The essence of the drum scheduling policy is therefore 
implemented in the algorithm which inserts drum Jobs in the 
queue: for once the queue is set up, it can only be 
modified by insertion of a new job or deletion of a finished 
job, and neither of these mechanisms will re-order the queue. 
Any scheduling policy we design will not, be dependent on 
the scheduling of iOOOOo-word jobs, since these are almost 
transparent with respect to drum position. 
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Sinee 400© -word file blocks all start at drum addresses 
divisible by 4G0g, the best performance we can expect from 
the drum is 40Q0g words transferred per revolution- This is 
obtained by placing the drum in operation for all even (odd) 
numbered blocks, while the odd (even) numbered blocks are 
passed over as the program restarts the drum. This is 
the best possible performance because delays in the drum 
field selection hardware make it impossible to set up a 
new drum transfer within the 8.6/ts spacing between words 
on the drum. 

Hence, the object of drum scheduling is to $ack the 
requested transfers into as little time as possible, while 
preserving a block of do-nothing time before and after 
every block of transfer time. 



Method 

The drum queue is composed of three data objects: 
a drum job queue head table j lOQg words; the drum job space, 
l40g words; and the overflow table, 20q words. The queue 
head table and the overflow table both contain pointers to 
drum jobs stored in the drum job space. A drum job entity 
requires three words with format as follows: 




FI£XJ) WMBIOCK 



CO RE ADDRESS 
POINT 
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R/ty gives the mode of transfer, FIELD and BIOCK specify the 
drum address, CORE ADDRESS is the translated memory address, 
and POIOT is a pointer to a list of processes to be made 
active when the Job is completed. Unused drum Job entities 
are held on a list. 

The queue head table is the scheduling data: the 100g 
words allow us to schedule iQOg blocks or 4 drum revolutions 
into the future, There will be a pointer to "now" in the 
queue (the queue is a ring buffer). If a word in the 
queue points to a drum Job, then it represents that drum 
Job. If a word in the queue has value 4Q00Q0g, then it 
represents "occupied time"* A zero word in the queue 
represents "available time". 

The drum Job scheduling algorithm is as follows; 
first, a drum Job entity for the Job is created. Then 
we attempt to schedule the Job by testing the four words 
in the queue capable of holding this Jobo We pick the 
earliest zero word, and load it with a pointer to the Job 
entity. Then we set the two words on either side to MOOOQg. 
If all four slots are filled, we place a pointer to the Job 
entity in the overflow table. About once every drum revolution 
we try to reschedule the overflow Jobs. 

When a drum transfer is actually started, the Job entity 
i& returned to the free list, and the associated words in the 
queue head table are zeroed. When the transfer has completed, 
we search the queue (linearly) for the next Job. 



